Program testing is an indispensable aspect of verification and validation process in any Program Development Cycle. It is the means of verifying a program. Coverage analysis is a part of testing, which improves the quality and dependability of program. Modified Condition/Decision Coverage analysis is a compulsion for many safety critical applications and it is rendered compulsory for DO-178B for level-A program certification.
The process of developing test cases is tedious and conventionally has been manual. Developing these test cases makes the developers and the program testers identify various segments/conditions/parts of the program code being executed for a particular set of test cases/test data. This, with the help of analysis tools, identifies whether a particular safety critical condition is getting executed or not. Depending on the test analysis a new set of test cases/test data are developed with an intention of covering segments/conditions/parts of the code not covered by the previous test cases/test data.
Requirements based testing may not be sufficient to test code structure of the program, because in many cases, there isn't an exact mapping between the requirements specifications and the actual code. Because of this drawback, there is a need for structural testing of the code. Structural testing is the way of measuring the extent to which the requirements based test data covered the code structure. If the requirements based test data do not satisfy a structural coverage criterion, then additional test data has to be generated until acceptable structural coverage is achieved.
Various types of structural coverage criteria are as follows    Function coverage    Statement coverage    Decision coverage    Condition coverage    Condition/Decision coverage    Modified condition/decision coverage (MCDC)    Multiple condition coverage
Referring to Kelly J. Hayhurst, Dan S. Veerhusen, John J. Chilenski and Leanna K. Rierson [“A Practical Tutorial on Modified Condition/Decision Coverage”], MC/DC analysis illustrates the independent effect of all the conditions present in a decision in a program code and subsumes all other structural coverage criteria except Multiple Condition coverage.
Code coverage is important since it significantly decreases the number of undetected bugs in the program. Thus, it improves the reliability of the program.
For complete coverage of the code, multiple condition coverage is ideal, but not practical. MCDC, therefore, provides the optimal practical alternative. Therefore, it has been rendered compulsory by DO-178B for level-A program certification.
The DO-178B definition of MC/DC includes the property that each condition is shown to affect the decision's outcome independently. This is done by varying only that condition and holding all other conditions fixed. This envisages achieving the independent effect of that condition. Independent effect is the property that sets apart MC/DC from the other coverage criteria because it guarantees a more comprehensive coverage as compared to the rest of the feasible structural coverage criteria. Therefore, MC/DC analysis is demanded by program manufacturers and standardization organizations.
The independent effect property of MC/DC influences the amount of test data to be created for a particular program. If the number of conditions present in the program is n, then the maximum test data that may have to be prepared is 2n, implying an average to a big test suite. But due to the following factors,
size and complexity of the code;    size and complexity of Boolean expressions in the code;    It becomes extremely difficult to prepare test data for a large, deeply nested decision which can be reached via multiple program paths;    Programmatic level of testing (unit level, functional level, module level);    the task of test suite preparation becomes more complicated and time consuming,
Preparation of test data that satisfy MC/DC for unit level testing is quite intuitive as compared to module level. Validation and modification of the prepared test data due to human errors also takes up a lot of manual time.
Automatic generation of test data for MC/DC coverage reduces the time and effort required to manually prepare the same test data. Thus, the overall time and cost of testing phase in software is reduced. This results in faster shipping of more reliable software.
P. Godefroid, N. Klarlund, and K. Sen. DART: Directed Automated Random Testing [Proceedings of PLDI'2005 (ACM SIGPLAN 2005 Conference on Programming Language Design and Implementation), pages 213-223, Chicago, June 2005] mentions automatic identification of interfaces between the program code with the working environment of the code and then applies random test values to test the code for general environment of the program. The paper also mentions the automatic generation of test cases to invoke alternative parts of the code. But, this document does not mention anything about the MC/DC analysis as the testing is random and doesn't guarantee invoking every condition in the program.
T. Ball, S. K. Rajamani The SLAM project—Debugging system program via static analysis [Proceedings of POPL'02 January] and Beyer, Henzinger, Jhala and Majumdar—The program model-checker BLAST [Springer-Verlag, September 2007] reveals Property Verification tools but doesn't mention generation of test data to verify the code.